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Implementation  of  High  Level  Architecture  into  the  MultiUAV  Research  Software 

Brian  Stolarik  and  Bill  Niland 
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Fairmont,  West  Virginia  26554 
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Abstract 

This  paper  describes  the  implementation  of  the 
Department  of  Defense’s  Mgh  Level  Architecture 
(HLA)  into  the  U.S.  Air  Force  Research  Laboratory’s 
multiple  unmanned  aerospace  vehicles  researdi 
software  (MultiUAV),  MultiUAV  allows 
simulations  of  multiple  UAV’s  cooperating  as  a  team 
to  accomplish  strongly  coupled  tasks.  Since  it 
operates  in  MathWorks’  Simulink  simulation 
envircMiment,  the  HLA  was  integrated  through  a 
series  of  S-fiinctions  written  in  C-H-.  The  addition  of 
the  HLA  into  MultiUAV  enables  more  realistic  inter- 
vehicular  communication  modeling  to  include  noise, 
latency,  and  data  dropouts.  It  also  enables  the 
distribution  of  MultiUAV  across  a  network  of 
computers.  Two  mission  scenarios  were  simulated 
both  with  and  without  the  HLA.  Identical  behaviors 
in  all  four  simulations  show  a  successful 
implementatiwi  of  the  HLA  into  the  MultiUAV 
research  tool. 

Introduction 

Future  generations  of  UAV’s  will  be  able  to 
autonomously  cooperate  with  either  manned  or  other 
unmanned  aorial  vehicles  to  accomplish  strongly 
coupled  tasks.  Such  cooperative  tasks  envisioned  by 
military  planners  include  combat  intelligence, 
surveillance,  and  reconnaissance,  aerial-based 
communication  nodes,  suppression  of  enemy  air 
defense,  identification  and  destruction  of  time  critical 
targets,  close  air  support,  cooperative  search,  and 
persistent  denial*’^^. 

Researchers  at  the  U.S.  Air.  Force  Research 
Laboratory  have  written  software  to  enable  their 
investigation  into  such  UAV  teaming  arrangements. 
MultiUAV^’^  is  a  MathWorks’  MATLAB/Simulink 
based  simulation  program  that  allows  cooperative 
algorithms  to  be  easily  tested  in  a  simulated  mission. 
Two  limitations  of  early  versions  of  the  software 
were  a  lack  of  realistic  inter-vehicular 
communication  modeling  and  the  inability  to 
distribute  the  software  across  a  computer  network. 
To  eliminate  these  issues  we  integrated  the 
Department  of  Defense’s  networking  standard  High 
Level  Architecture  (HLA)  into  the  software. 


Brief  overviews  of  the  HLA  and  MultiUAV  are  given 
before  a  discussicm  of  the  work  completed  to  merge 
the  two.  The  simulation  results  of  two  missions  with 
increasing  complexity  are  presented  in  the  results 
section.  Finally,  we  discuss  some  conclusions  and 
future  work. 

The  High  Level  Architecture 

In  1996  the  U.S.  Department  of  Defense  released  the 
High  Level  Architecture  as  its  standard  for 
communication  between  distributed  simulations.  In 
2000,  the  Institute  of  Electronics  and  Electrical 
Engineers  (IEEE)  adopted  the  HLA  as  IEEE  Standard 
1516.  A  brief  overview  of  the  HLA  will  be  given 
below  but  interested  readers  are  urged  to  consult  one 
of  the  published  references^*’**  for  a  more  detailed 
explanation. 

The  HLA  is  a  software  ardiitecture  designed  to  allow 
simulations  to  be  interoperable,  distributed  and 
reusable.  Such  capabilities  provide  the  simulation 
designer  the  ability  to  interact  their  HLA  compliant 
simulation  with  any  other  HLA  compliant  simulation. 
These  individual  simulations,  or  federates,  can  be 
mixed  and  matched  to  create  a  master  simulation,  or 
federation.  The  HLA  is  additionally  flexible  in  that 
it  does  not  require  simulations  to  be  written  in  a 
specific  programming  language.  In  fact,  separate 
components  of  the  simulation  can  be  written  in 
different  languages  and  still  be  interoperable. 

An  HLA  federation  is  a  set  of  federates  defined  by 
the  HLA  interface  specifications  that  interact  by 
exchanging  data.  This  data  exchange  is 
accomplished  through  an  interface  common  to  all 
federates  on  the  same  network  known  as  the  Run 
Time  Infrastructure  (RTI).  The  RTI  provides  a  set  of 
services  that  a  federate  can  use  to  send  data  to  and 
receive  data  fi-om  other  federates.  The  RTI  also 
manages  the  federation. 

Four  of  the  six  services  provided  by  the  RTI  to  a 
federate  were  used  in  this  research: 

1)  Federation  management  services  provide  a  set  of 
functions  a  federate  can  call  to  create,  join, 
resign,  and  destroy  a  federation. 
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2)  Object  management  services  allow  a  federate  to 
register  and  discover  objects  within  the  federate. 

3)  DecIaraticMi  management  services  specify  what 
data  will  be  provided  and  required  by  the 
federate  during  execution. 

4)  Time  management  services  enable  federates  to 
send  and  receive  time  stamped  data.  It  also 
allows  federates  to  be  time  synchronized,  an 
important  feature  for  distributed  simulations. 

MultiUAV 

The  MultiUAV  simulation  software  allows 
researchers  to  examine  cooperative  control 
algorithms  in  multiple  UAV  mission  scenarios.  In 
the  latest  public  release  of  MultiUAV^  researchers 
can  adjust  the  number  of  vehicles  (maximum  of  8) 
and  targets  (maximum  of  10)  in  the  simulated 
mission.  The  goal  of  the  mission  is  to  find,  classify 
and  attack  targets  in  a  seardi  area.  Since  the  UAV’s 
are  homogeneous  and  modeled  as  a  Low  Cost 
Autonomous  Attack  System  (LCX^AAS),  an  attack  by 
a  vehicle  terminates  its  existence.  Thus,  the  number 
of  vehicle  alive  during  the  simulation  decline  as 
targets  are  attacked.  After  an  attack,  another  vehicle 
must  fly  over  the  target  to  do  battle  damage 
assessment.  Vehicles  that  remain  after  all  targets  are 
destroyed  simply  continue  their  search  mission. 

The  goal  of  the  coordinated  control  algorithms  under 
investigation  within  MultiUAV  is  to  optimally^^  if 
possible  and  feasible,  allocate  the  mission’s  tasks 
among  the  vehicles.  At  the  beginning  of  the  mission 
the  vehicles  start  a  predetermined  search  pattern. 
Once  a  vehicle  detects  a  target  it  notifies  all  other 
vehicles,  triggering  a  replan.  Once  triggered,  the 
coordinated  control  algorithm,  duplicated  on  each 
vehicle  to  maximize  autonomy,  calculates  the  next 
set  of  tasks  for  all  known  vehicles.  The  algorithm 
duplication  allows  each  vehicle  to  compute  the  same 
set  of  tasks  for  all  vehicles  without  substantial  inter- 
vehicular  communication. 

Implementing  the  HLA  into  MultiUAV 

Since  MultiUAV  was  written  in  the 
MATLAB/Simulink  environment,  making  it  easily 
understandable  and  modifiable  to  outside  researchers, 
the  options  for  integrating  the  HLA  into  the  software 
is  limited  to  Simulink  S-Functions*‘.  S-Functions  are 
compiled  code,  C-H-  in  this  research,  which  users 
write  to  extend  Simulink’s  predefined  functionality. 
Simulink  simply  passes  data  to  and  receives  data 
fi*om  a  user  defined  S-Function. 

Figures  1  and  2  illustrate  conceptually  how  S- 


Functions  were  used  to  remove  the  communication 
bus  within  MultiUAV.  Figure  1  shows  the 
connections  of  n  targets  and  m  vehicles.  The 
simulation  bus,  shown  in  red,  only  passes  truth 
information  between  vehicles  and  targets.  The 
communication  bus,  shown  in  green,  models  the 
communication  between  vehicles.  Again,  these 
figures  are  only  meant  to  convey  a  concept  since  the 
latest  MultiUAV  (not  publicly  released  at  the  time  of 
this  writing)  actually  uses  a  common 
communications  memory  structure  instead  of  direct 
block  connections.  The  eliminatiai  of  the 
communication  bus,  not  the  simulation  bus,  was  the 
focus  of  this  research  . 


Figure  1:  Original  communication  design 


Figure  2:  Modified  communication  design 

Figure  2  illustrates  the  new  communication  design 
that  incorporates  the  HLA.  Notice  that  in  the  new 
design  inter-vehicular  communication  is  achieved 
through  the  RTI  via  S-Functions.  Each  vehicle  has 
its  own  S-Function,  labeled  “RTI  out”,  that  sends  the 
data  received  fi-om  Simulink  to  the  RTI.  Also,  all 
vehicles  share  a  single  S-Function,  labeled  “RTI  in”, 
that  receives  the  data  from  the  RTI  and  makes  it 
available  to  Simulink.  Each  S-Function  is  seen  as  a 
federate  to  the  RTI.  The  forcing  of  inter-vehicular 
communication  to  pass  through  the  RTI  is  a  first  step 
toward  making  MultiUAV  distributable  across  a 
network.  Additionally,  other  federates  can  connect  to 
the  RTI  outside  of  Simulink  or  MultiUAV,  enabling 
them  to  receive  any  data  the  vehicles  send.  Such  a 
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federate  might  be  a  passive  data  logger,  a  bandwidth 
filter,  or  a  communication  model  to  allow  researchers 
to  artificially  inject  noise,  dropouts,  or  latencies. 

The  implementation  of  Figure  2  occurred  at  the  top 
levels  of  the  MultiUAV  Simulink  mcxlel.  The 
original  vehicles  subsystem  can  be  seen  in  Figure  3. 
Only  the  first  two  vehicles  out  of  a  possible  eight  are 
shown  for  brevity. 


Figure  3:  Original  Vehicle  Subsystems 

Since  each  S-Function  is  seen  by  the  RTI  as  a 
federate,  each  requires  unique  parameters  to  operate, 
e.g.  a  federate  name.  For  this  reason  and  ease  of  use, 
each  vehicle’s  S-Function  was  placed  outside  of  the 
vehicle  model.  A  small  modification  was  made  to 
the  vehicle  model  to  allow  passing  of  the 
communication  outside  of  the  vehicle  and  into  the  S- 
Function.  Figure  4  illustrates  the  vehicles  tied  to  the 
HLA  interface  S-Functions,  which  are  shown  in 
green.  The  additional  input  to  the  vehicle  block  is 
simply  a  flag  that  allows  the  user  to  toggle  between 
the  original  communication  system  and  our  HLA 
system  for  testing  purposes. 


Figure  4;  Modified  Vehicle  Subsystems 


Messages  in  the  original  MultiUAV  were  triggered 
and  written  to  memory  only  when  pertinent  for  other 
vehicles.  Figure  5  shows  the  original  message 
passing  system  found  in  each  vehicle. 


Figure  5:  Original  Message  Passing  Subsystem 


This  message  triggering  system  worked  very  well  for 
an  HLA  implementation.  Extra  output  ports  were 
created,  allowing  for  the  message  trigger  and  the  data 
to  be  passed  outside  the  vehicle  block.  The 
triggering  concept  keeps  network  bandwidth  to  a 
minimum.  The  modified  message  passing  system 
can  be  seen  in  Figure  6. 


Figure  6:  Modified  Message  Passing  Subsystem 

Each  message  passing  subsystem’s  outputs  are  thai 
multiplexed  together  to  form  a  single  HLA  bus. 
Referring  to  Figure  4,  this  bus  is  subsequently 
injected  into  the  RTIout  S-Function.  Once  the  data  is 
received,  the  S-FuncticHi.  parses  the  vector,  checking 
to  see .  if  any  particular  message  has  a  trigger 
associated  with  it.  Any  messages  with  triggers  are 
wrapped  together  and  sent  to  the  RTI. 

The  triggered  data  that  is  sent  through  the  RTI  is 
reflected  at  the  RTTin  S-Function.  At  each  Simulink 
time-step,  the  S-Function  invokes  a  tickQ  command 
to  the  RTI,  yielding  time  for  its  calltecks  to  be 
executed.  These  callbacks  dynamically  create  and 
fill  a  vehicle  memory  table,  storing  the  data 
temporarily  until  the  S-Function  can  read  and  send  it 
to  the  Simulink  model.  A  total  of  ten  messages  can 
be  reflected  at  the  RTIout  S-Functicm.  When  a 
message  is  reflected,  the  data  along  with  its 
timestamp  are  placed  on  individual  output  ports,  thus 
20  outputs  can  be  found.  After  expanding  the  RTTin 
sub-system  in  Figure  4,  the  S-Function  can  be  found. 
This  is  seen  in  Figure  7. 


Figure?:  RTIin Subsystem 
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This  configuration  of  output  ports  is  used  since  each 
vector  can  change  in  width  without  effecting  the 
simulation.  The  bus  hierarchy  is  created  to  place  no 
emphasis  on  indexing  the  vector  to  extract  messages. 
This  concept  was  directly  modeled  fi*om  the  existing 
MultiUAV  communication  passing"^. 

Simulation  Results 

Two  scenarios  using  the  same  control  algorithm  were 
tested  with  increasing  complexity  to  verify  the  HLA 
communication’s  dependability.  The  individual 
scenarios  were  executed  twice,  the  first  using  the 
original  communications  design  for  data  exchange 
while  the  second  used  the  HLA.  The  data  passed  to 
and  received  from  the  S-Fiinctions  was  then 
compared.  The  results  presented  are  for  the  HLA 
design  versus  the  original  MultiUAV 
communications  architecture. 

Mission  1:  The  first  mission  scenario  tested  included 
three  vehicles  and  one  target.  In  this  mission,  vehicle 
1  finds  the  target,  vehicle  3  is  tasked  to  confirm  and 
kill  the  target,  and  vehicle  1  finishes  the  mission  by 
confirming  the  kill.  Vdiicle  2  is  not  tasked  for  target 
1  so  it  continues  its  original  search  mission. 

Figure  8  shows  a  snapshot  of  this  simulation  using 
the  original  communications  design  at  62.30  seconds. 
Vehicle  1  has  already  detected  the  target  while 
vehicle  3  is  approaching  for  the  kill.  Figure  9  shows 
the  same  simulation  using  the  HLA  communications 
design. 

The  change  in  background  color  is  intentional  to 
distinguish  between  the  two  comparisons.  This 
snapshot  shows  an  exact  match  between  the  original 
communication  and  the  HLA  design. 

Table  1  shows  the  event  flow  for  the  first  mission 
scenario.  The  left  two  columns  of  the  table  document 
the  major  simulation  events  before  HLA,  while  the 
right  two  columns  document  the  events  after  HLA. 

The  matching  of  events  and  event  times  verifies  that 
the  cooperative  control  algorithm  behaves  identically 
wdth  either  communication  design.  Thus,  the  added 
capabilities  of  the  HLA  have  been  integrated  into 
MultiUAV’s  communication  scheme  without 
affecting  the  algorithm  in  this  simple  mission 
scenario 

Mission  2:  The  second  mission  scenario  tested  is 
significantly  more  complicated  in  that  it  included 
eight  vehicles  and  five  targets.  Vehicles  1,  2,  4,  5, 
and  6  locate  the  five  targets  to  begin  the  simulation. 


Figure  8:  Mission  Scenario  1  Without  HLA 
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Figure  9:  Mission  Scenario  1  With  HLA 
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Tablet:  Even  Flow  Chart  for  Scenario  1 


Vehicles  1,  5,  6,  7,  and  8  c^  out  the  t^get 
execution.  The  simulation  is  finished  when  vehicles 
2,  3,  and  4  perform  the  kill  verificaticxi.  The 
simulation  before  HLA  introduction  is  highlighted  in 
Figure  10. 
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Figure  10;  Mission  Scenario  3  Before  HLA 

This  snapshot  is  taken  88.20  seconds  into  the 
simulation.  All  targets  have  been  identified  and 
tasking  has  been  decided  upon  through  the  algorithm. 


For  this  last  scenario,  the  HLA  simulation  in  Figure 
1 1  is  identical  to  the  original  communication  design 
simulation.  All  vehicles  are  on  the  same  course  of 
action,  showing  the  algorithm  is  behaving  the  same. 
Table  2  shows  a  simulation  event  flow  chart  of  the 
individual  steps  for  this  mission  scenario.  As  in  the 
first  scenario,  the  integration  of  the  HLA  has  not 
affected  MultiUAV’s  algwithm  performance. 


Time  Managed  HLA 

It  is  important  to  note  that  the  above  HLA  results  use 
RTI  time-management  services.  The  initial  HLA 
integration  used  no  time-management  and  yielded 
similar  results.  However,  a  detailed  analysis  of  the 
data  revealed  that  each  message  contained  a  small 
percentage  of  dropouts.  Depending  on  the  message, 
the  dropout  rate  varied  from  0.1  to  15  percent 

Using  the  provided  routines  in  the  RTI  timing 
queues,  the  data  dropout  was  corrected  and  the 
messages  passed  using  either  communication  design 
were  identical.  This  will  prove  to  be  useful  when  the 
simulation  is  distributed  across  multiple  Simulink 
models. 


Though  MultiUAV  runs  dependable  with  time 
management,  it  runs  six  to  seven  times  slower  due  to 
the  synchronization  requests  between  each  vehicle  at 
every  time-step.  Finding  ways  to  speed  up  the  RTI 
will  be  the  focus  of  future  work. 


Figure  11:  Mission  Scenario  3  After  HLA 
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7.90 
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33.10 

Targetl  Detected 

33.10 

Targetl  Detected 

39.56 

UAVl  Finds  Targets 

39.56 
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41.74 
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41.74 
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42.50 
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42.50 

Targets  Detected 

50.40 

Target4  Killed 
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66.84 

UAV6  Finds  Targetl 
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70.60 

Target2  Confirmed 

75.50 

Targetl  Killed 

75.50 

Targetl  Killed 

92.06 

UAV3  Finds  Target4 

92.06 

UAV3  Finds  Targct4 

94.20 

Target4  Confirmed 
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UAVl  Finds  Targets 
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108.90 
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108.90 
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110.70 

Targets  Confirmed 

110.70 

Targets  Confirmed 

117.60 

UAV2  Finds  Targetl 

117.60 

UAV2  Finds  Targetl 

119.80 

Targetl  Confirmed 
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Targetl  Confirmed 

125.60 

UAV3  Finds  Targets 

125.60 

UAV3  Finds  Targets 

127.80 

Targets  Confirmed 

127.80 

Targets  Confirmed 

Table  2:  Event  Flow  Chart  for  Scenario  2 
Conclusions  and  Future  Work 

The  paper  described  the  sufcessful  replacement  of 
the  original  communication  design  within  MultiUAV 
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with  an  HLA  communication  design.  The  software 
was  tested  in  two  mission  scenarios  designed  to 
challenge  the  new  design  at  extreme  scenarios  and 
stress  the  RTI.  In  both  scenarios  the  modified 
MultiUAV  performed  identically  to  the  original 
MuItiUAV.  Therefore,  the  added  capabilities  of  the 
HLA  have  been  integrated  into  MultiUAV’s 
(xmimunication  sch«ne  without  affecting  the 
perfcxmance  of  the  coordinated  control  algorithm. 

Future  work  on  MultiUAV  will  include  the 
elimination  of  the  simulation  bus,  the  addition  of  a 
central  control  federate  that  will  act  as  a  data  logger, 
bandwidth  filter,  and  a  communication  model,  and 
the  formatting  of  messages  into  Link  16  to  allow 
MultiUAV  to  communicate  with  the  Joint  Integrated 
Mission  Model. 
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